1. Field of the Invention
The invention relates to a method for using a common resource, and to a hardware component including a plurality of virtual machines.
2. Description of the Related Art
Personal computers and similar customary hardware architectures are being increasingly used to implement programmable logic controllers (i.e., soft PLCs). As a rule, what are referred to as real-time operating systems are used for these programmable logic controllers, where the operating systems are therefore configured or changed to meet stringent requirements, such as reaction times, cycle times or operating reliability. In this context, virtualization techniques are often applied, i.e., a virtualization controller/virtualization software (Virtual Machine Manager, Hypervisor) is used to allow the real-time operating system to run in a separate virtual running time environment. If other orders are also to be performed with the same hardware platform, non-real-time operating systems (i.e., “general purpose operation systems”), can also be made to run in parallel in further virtual machines.
If both operating systems in such an architecture access a resource that is only present once (for example, a network card or an IDE controller), the access to the resource is coordinated by the hypervisor in a synchronization component. Here, the non-real-time operating system whose structure often cannot be changed, accesses the hardware of the resource directly, in which case these access operations have to be intercepted and correspondingly coordinated by the hypervisor to be able to perform the order of the non-real-time operating system in a “quasi-parallel” manner with respect to orders of the real-time operating system.
In principle, it is equally possible to perform an access operation at the real-time operating system, but it is advantageous not to have recourse to a driver in a way which is analogous to the non-real-time operating system but rather to use a para-virtualized driver, which means that the real-time operating system has knowledge of how it is running under the control of the hypervisor and interacts therewith in an optimized way.
Ideally, the above-described procedure is configured such that waiting times (for example, polling on the hardware register) for the resource do not adversely affect the real-time operating system in terms of its real-time performance. In particular, waiting times must not be shifted back in the hypervisor during the interruption of the real-time operating system. Nevertheless, an unavoidable delay occurs during the interaction with the hypervisor, precisely as a result of the implied or programmed exit (“VmExit”) into the hypervisor, such as a result of monitoring of memory addresses, IO addresses or PCI Config-Space, of the accessed resource or as a result of a hypercall in the para-virtualized approach. The entirety of this delay is included in the real-time performance, i.e., in the interrupt latency time.